Tables that may contain multiple versions of a row are referred to herein as versioned tables. If there are v versions for r rows to store in the table, then the total number of rows in the table is v*r. For example, if there are 5 versions for 1000 rows, then the total number of rows is 5*1000, which is 5000.
Versioned tables, as with other types of tables, may be indexed so that the tables may be accessed more efficiently. An approach for indexing a versioned table is the entry-per-version approach. Under the entry-per-version approach, an index has one entry for each version of a row in the table. Thus, the size of an index is proportional to the number of row versions stored in a table.
A problem with indexes created under the entry-per-version approach is that the approach inflates the number of entries in an index for a table with a given number of rows because the index contains multiple entries for each row, one for each version, even if the versions are identical. Indexes with a greater number of entries inherently require more data processing when scanning or traversing the indexes, and are therefore less efficient to use than an index with a lesser number of entries.
Applications that access versioned table are generally interested in one version of rows. Therefore, there is need for an approach that allows applications to retrieve and process only those rows that belong to a particular version of interest. One such approach is the application-level approach. Under the application-level approach, applications themselves are programmed with logic needed to retrieve and process rows of a given version. Programming applications with such logic complicates the already complex task of developing applications.
Based on the foregoing, it is clearly desirable to provide a mechanism that reduces the amount of data that has to be processed when using indexes that index versioned tables and that reduces or eliminates the need to program applications that process data from a versioned table.